Right Sizing Reference Architectures

The growing complexity and size of systems and the organizations that create these systems trigger the need for instruments that facilitate the creation of these systems. We shortly analyze these trends and the (potential) role of reference architectures as facilitating means. After a short discussion about the content of Reference Architectures and their relation with system architectures, system design and actual systems, we zoom in on the question what the appropriate level of detail is for Reference Architectures. We discuss an evolutionary approach to create and maintain Reference Architectures Introduction Reference Architectures are one of the means to cope with the increasing size and complexity of the development of systems. Especially when a multitude of context constraints are imposed, such as multi-site, multi-vendor, and multi-organization, Reference Architectures form a powerful instrument. The trend towards more integration and more dynamics further increases the value of Reference Architectures. Reference Architectures capture proven architectural patterns and use these in an architectural blueprint. The blueprint provides guidance to multiple organizations, and multiple sites how to create new products or product families, or how to extend existing products. One of the values of Reference Architectures is to provide a common architectural vision, and common lexicon and taxonomy, to the heterogeneous set of involved stakeholders. Reference Architectures also support the increased integration of systems, where the main challenge is to achieve interoperability between different and evolving systems. Reference Architectures explicitly articulate domain and realization concepts, and model functions and qualities above system level. Together with explicit decisions about compatibility, upgrades, and interchangeability a framework is created to integrate different systems in useful ways. Reference Architecture Content Reference Architectures go well beyond the system boundaries, because specification and design decisions have their rationale in the system context. Figure 1 shows a decomposition of a Reference Architecture into technical architecture, customer context, and business architecture. The technical architecture captures design pattern and technology considerations. The interface between the technical architectures and the contexts are the requirements, which provide a black box view on the systems. A Reference Architecture captures the essence of the usage domain, with information about for instance customers, users, or the enterprise context. The business architecture captures the underlying business